|
DTAP
DTAP stands for Development, Test, Acceptance and Production. The basic principle of the model is that every user of
the infrastructure wants to do his or her job undisturbed, without being hindered by anyone else. For instance, the end
user does not want to be bothered by the tester, who in turn wants to be left alone by the programmer. This is why a
separate type of environment is defined for each of these parties. The 4 environment types are analogous to the 4
stages software goes through: the software is developed (development), tested (test), accepted (acceptance) and used
(production).
While the DTAP model may initially look like a technical solution, it is not. The model does not prescribe that there
are 4 environments, but simply that there are 4 environment types. Each of these 4 types has its own characteristics.
As such, the DTAP model makes allowance for the use of 7 environments, for instance, in a project (see
figure 1 - Different environments in a development project according to the DTAP model). There
might be two development environments (local and centralised), one test environment, two acceptance environments (user
acceptance test and production acceptance test environment), and two production environments (production and shadow).
Figure 1: Different environments in a development project according to the DTAP model
Owners and administrators of the environment types
Test activities can be executed in every environment type of the DTAP model. Since every environment has an owner,
administrator (manager) and its own group of users, the various activities have their own characteristics. For instance,
the test environment type is managed differently than the production environment type. In the DTAP model, it is important
to distinguish which parties are the owners or administrator of each type of environment. The owner is the party who
determines which users are allowed and what the administrators need to do. In the DTAP model, the aim for which the
environment is used determines the owner. Sometimes the owner is also the economic owner, but not necessarily.
In the development environment type, it is generally clear who the owner and administrator are. Both roles are fulfilled by
the programmers. They acquire and maintain the environment. It is equally clear for the production environment type. The
user organisation is the owner, and often the maintenance is handled by a special maintenance organisation (on behalf of
the user organisation).
For the test and acceptance environment types it is often a bit more complicated because multiple parties are involved. The
user organisation is the owner of the acceptance environment and the testers are the owners of the test environment. But
the environments can be maintained by several parties. It may have been acquired by either the project or the maintenance
department. In the latter case, the maintenance may be handled by the maintenance department or the testers
themselves. The maintenance can even be in the hands of the developers.
|
Environment type
|
Owner
|
Administrator
|
|
Development
|
Developers
|
Developers
|
|
Test
|
Testers
|
Developers/Testers/Maintenance
organisation*
|
|
Acceptance
|
User organisation
|
Developers/Testers/Maintenance
organisation*
|
|
Production
|
User organisation
|
Maintenance organisation
|
* = different possible options
Table 1: The possible owners and administrators of the 4 environment types.
Test types and the 4 environment types
The DTAP model does not impose a consistent link of a test type to one environment type. This is to prevent
negative consequences. Because of the consecutiveness of the test process in the test environments defects may be
discovered too late. This can be prevented by executing a test type in more than one environment type. Clearly, the
delivery of the testable parts of the test object must be related to the test type (and the associated environment). In
this construction, the user may execute some tests in the development environment.
The realisation of this model is a challenge for the test management and stakeholders. The owner of the environment
must accept that his environment may be used for any test type. Different user groups can use the environment. The time
gain that can be achieved thanks to parallelism of the tests and reduction of the repair costs due to earlier detection
of defects are more than worth the effort. It is therefore especially important that the test environment fit the test
type, in the DTAP model this is a perfect fit.
Tests in the development environment type
The unit test is executed in the same environment type in which the software and other system components
are developed: the development environment. Setting up this environment and the related test activities are executed as
part of the development process. When a part of the environment must be used for a test, the developer himself is
usually the party arranging this. Often the development platform contains standard facilities for testing, such as
files, test tools and procedures for e.g. version management, transfer, defect administration and defect repair. These
facilities offer the developers adequate options to manage their test process correctly. If there are no specific
requirements for the unit tests and the above standard facilities are available, the tests can be executed correctly.
An important aspect that programmers must deal with is the manageability of their environment. In practice, a
programmer often has five or more versions of his software under management. Maintaining the relationship between the
test cases, test results and the test object requires a lot of attention in this case.
Tests in the test environment type
The test environment type is created to test (parts of) the entire system for both technical and functional aspects.
This test must be executed in a manageable environment. Manageable means that resources are available to transfer and
manage, among other things, the software, documentation, test files and testware. The tester must be able to control
the transfer of new or changed software. The tests must be reproducible. It must be possible to execute the individual
tests of one (sub-)system separately from the tests of other (sub-)systems. The simultaneous use of the same test data
in particular may cause a lot of trouble. In this environment type, tools can be used that provide the tester with
insight at a technical level into various events. Examples are the use of SQL to look directly in the database, having
direct access to the system’s log files, and being able to start up and stop batches.
Tests in the acceptance environment type
The acceptance environment type offers future users and managers the possibility to test the test object in an
environment resembling the production environment as closely as possible. Usually the test in this environment type is
split up into a user acceptance test and a production acceptance test. The UAT checks whether the test object provides
the required functionality in relation to production facilities and procedures. The PAT checks whether the system
complies with the management and production standards, in terms of both procedures and aspects like volume processing
and performance. It is preferable to create a separate environment for the test types UAT and PAT, although it is
naturally possible to execute them in the same environment.
The PAT environment as a production environment
Organisations often feel that a test environment for the PAT is costly. Not surprising, because it is
especially important for the PAT that the test environment is not only functional, but even more so technically
equivalent to the production environment. Logically, this means that a PAT environment requires the same hardware as
the production environment (types and quantities). As such, a PAT environment is a second production environment.
A solution is, in new development processes, to promote the PAT environment to production environment when the system
is delivered. This means only one production environment is necessary. In maintenance projects, an option is to execute
the PAT in a fallback environment, which is often a copy of the production environment. If there is no fallback
environment, it can be decided to execute the PAT in the production environment at a moment when there are no users
(e.g. at night or during the weekend). Clearly this last option involves some risk in terms of availability of the
production systems – it is therefore recommended exclusively for relatively simple systems.
Tests in the production environment type
Testing in an environment that is used for production is not desirable, and sometimes even prohibited by regulatory
bodies and other supervisors. In very exceptional situations, it is sometimes unavoidable to test in the production
environment type. In these cases, the required test environment is so complex that it cannot be simulated or built.
Example is a complex system chain (often across several organisations or even countries). In this type of cases,
in-production testing is an option. But a lot of things have to be arranged for that purpose. For instance, the new
version of the software must be accessible exclusively to the test team. Furthermore the execution of the test must not
disturb the regular production process. Furthermore an (external) supervisor often checks the test execution because
operations are executed (orders, payments, etc) that are not formal.
|
